Общий курс · осенний семестр · занятие 7 из 15

UML, часть 2: диаграммы поведения

О чём эта тема: Диаграммы, описывающие жизнь системы во времени: последовательности, состояний и деятельности — плюс кому какие диаграммы нужны в работе и в каком инструменте их рисовать.
Аннотация: Продолжение занятия 6. Сначала разбирается диаграмма последовательности: линии жизни, стереотипы классов и фреймы с операторами взаимодействия. Затем — дописанная диаграмма состояний: состояния объекта и правила переходов, с мостиком к машинам состояний из траектории «Геймдев». Третья диаграмма — деятельности: блок-схема процесса с развилками, параллельными ветками и сигналами; её элементы собраны в справочную таблицу. Практическая часть отвечает на вопросы «какую диаграмму выбрать под задачу» и «кому какие диаграммы нужны» — от заказчика до разработчика, — и завершается выбором инструмента.
Пререквизиты: Занятие 6: нотация UML (актор, юзкейс, класс, связи) и диаграммы структуры — без них термины этого занятия повиснут в воздухе.
Мотивация: Диаграммы занятия 6 отвечают на вопрос «из чего состоит система», но молчат о главном для программиста: что происходит, когда пользователь нажимает кнопку. В каком порядке объекты обмениваются сообщениями? Через какие состояния проходит заказ? Где процесс ветвится и где идёт параллельно? На эти три вопроса отвечают три диаграммы поведения — и именно их чаще всего просят разработчики.

1. Диаграмма последовательности

Диаграммы последовательности (sequence diagram) уточняют диаграммы вариантов использования: они детально описывают логику сценария — как и в каком порядке взаимодействуют элементы системы. Ключевое слово — «последовательность»: диаграмма показывает хронологию, то есть когда, как и в какой очерёдности передаются сообщения.

Линии жизни (пунктир), полосы активации и сообщения: сплошные стрелки — вызовы, пунктирные — ответы; время течёт сверху вниз

Помимо обычных участников, на диаграммах последовательности используются три стереотипа классов — они подсказывают роль объекта:

Стереотип	Роль	Обозначение
Разграничитель (boundary)	Отделяет систему от внешней среды: экранная форма, пользовательский интерфейс, устройство ввода-вывода.
Контроллер (control)	Активный элемент, выполняющий операции над объектами: программный модуль, обработчик.
Сущность (entity)	Хранит информацию о бизнес-объектах: соответствует таблице или элементу базы данных.

1.1. Фреймы и операторы

Фрейм — рамка, объединяющая часть взаимодействия; в её углу ставится метка оператора, которая говорит, как выполнять содержимое:

sd — очерчивает всю диаграмму последовательности;
alt — альтернативы: несколько фрагментов, выполняется тот, чьё условие истинно;
opt — необязательный фрагмент: выполняется только при истинном условии (alt с одной веткой);
neg — недопустимое взаимодействие: последовательности, запрещённые явно;
break — сценарий завершения: при истинном условии выполняется фрагмент, остальная часть фрейма игнорируется;
par — параллельные фрагменты; critical — критический регион с единственным потоком за раз;
loop — цикл: фрагмент выполняется несколько раз;
ref — ссылка на взаимодействие с другой диаграммы.

Пример фрейма alt: две альтернативные ветки взаимодействия с условиями — Фрейм alt: выполняется ветка с истинным условием

Пример фрейма loop: повторяющийся фрагмент взаимодействия с условием итерации — Фрейм loop: тело повторяется, пока условие истинно

2. Диаграмма состояний

Диаграмма состояний (state machine diagram) описывает жизненный цикл одного объекта: в каких состояниях он бывает и по каким правилам переходит между ними. Элементов немного:

состояние — прямоугольник со скруглёнными углами;
переход — стрелка с подписью события или условия, которое его вызывает;
начальное псевдосостояние — закрашенный кружок: откуда всё начинается;
конечное состояние — кружок в кольце («бычий глаз»): здесь жизненный цикл завершается.

Жизненный цикл заказа: события на стрелках запускают переходы; из «оплачен» возможна отмена с возвратом денег

Правила чтения: в каждый момент объект находится ровно в одном состоянии; переход срабатывает только по подписанному событию; события без подходящего перехода игнорируются (заказ в состоянии «создан» нельзя «вручить»). Именно поэтому диаграмма состояний — лучший способ обсудить с заказчиком тонкие места: «а можно ли отменить уже отгруженный заказ?» — и увидеть ответ по наличию или отсутствию стрелки.

Знакомая картина? Это та же машина состояний, что и в траектории «Геймдев»: в конспекте A02 ею описан противник, а в A11 она превращена в работающий код. UML-диаграмма состояний — стандартный способ нарисовать такую машину до того, как писать switch.

3. Диаграмма деятельности

Диаграмма деятельности (activity diagram) отображает динамику процесса: блок-схема, показывающая, как поток управления переходит от одного действия к другому. Если диаграмма состояний следит за одним объектом, то диаграмма деятельности — за процессом целиком: с развилками, слияниями и параллельными участками.

Пример диаграммы деятельности: последовательность действий процесса с развилкой и параллельными ветками — Пример диаграммы деятельности

Элемент	Назначение	Обозначение
Начальный узел	Начало процесса.
Действие	Главный строительный блок: шаг моделируемого процесса.
Переход	Передача управления от действия к действию.
Узел решения	Ветвление: минимум два выхода с условиями (обычно «да/нет»).
Разветвитель (fork)	Один поток разделяется на несколько параллельных.
Синхронизатор (join)	Несколько параллельных потоков сливаются в один.
Передача сигнала	Создаёт сигнал и отправляет его цели.
Приём события	Ожидание наступления события.
Условие	Сторожевое условие перехода в квадратных скобках.
Финал потока	Завершение одного потока, процесс продолжается.
Конечный узел	Окончание процесса в целом.
Комментарий	Пояснение к действию, переходу, старту или финалу.

Типичная ошибка Путать узел решения с разветвителем. Ромб — «или»: поток пойдёт по одной ветке, выбранной условием. Жирная черта fork — «и»: поток разделяется, и все ветки выполняются параллельно, а собрать их обратно обязан синхронизатор. Перепутанные, они описывают принципиально разные процессы.

4. Какая диаграмма под какую задачу

Задача	Диаграмма
Описать взаимодействие пользователя с системой и её функциональность	вариантов использования
Раскрыть последовательность действий конкретного прецедента	деятельности
Разделить объекты на классы, описать их свойства и связи	классов
Описать жизненный цикл класса и условия переходов	состояний
Показать, как объекты обмениваются данными во времени	последовательности
Описать архитектуру	пакетов, компонентов, развёртывания

4.1. Кому какие диаграммы нужны

Заказчику — диаграмма прецедентов, чтобы понятным языком описать желаемое, и диаграммы классов для верхнеуровневых требований; при согласовании финальных требований — деятельности, состояний и развёртывания. Сами заказчики редко изучают модели самостоятельно, но они незаменимы на интервью, при уточнении требований и презентации решений.

Аналитику — прецеденты для сбора требований, классы для проектирования, а для согласования с командой и заказчиком — деятельности, состояний и последовательности. Порядок работы: ролевая модель диаграммой прецедентов (её удобно набрасывать прямо на интервью) → объекты и связи диаграммой классов → процессы диаграммой деятельности → детальная логика диаграммой последовательности, самой полезной для разработчиков.

Типичная ошибка Путать диаграмму прецедентов с текстовым форматом описания прецедента (use case). Это разные инструменты, которые дополняют, а не заменяют друг друга: написанный текстом сценарий иллюстрируется диаграммой.

Проектировщику — развёртывание для архитектуры решения; компоненты и пакеты для согласования с командой, безопасностью, DevOps и поддержкой. Разработчик чаще принимает чужие модели, чем рисует свои: для структуры решения ему нужны классы и состояния, для согласования — деятельность и последовательности (с ними разработчики сталкиваются чаще всего).

4.2. Инструменты

Draw.io — бесплатный, исключительно простой, работает в браузере; после запуска предлагает тип диаграммы и создаёт черновик. Для занятий курса — основной выбор.
StarUML — профессиональный настольный инструмент (Windows, macOS): сложнее в освоении, мощнее по возможностям, платная лицензия.
Lucidchart — универсальная онлайн-доска с шаблонами и упором на совместную работу команды.

Контрольные вопросы

Линия жизни (пунктир вниз от участника) — существование объекта во времени; полоса активации на ней — интервалы, когда объект выполняет работу. Время течёт сверху вниз, сплошные стрелки — вызовы, пунктирные — ответы.
Boundary отделяет систему от внешней среды (экранная форма, интерфейс); control выполняет операции (модуль, обработчик); entity хранит данные бизнес-объектов (таблица базы данных).
Alt содержит несколько альтернативных веток — выполняется та, чьё условие истинно; opt — одна необязательная ветка (alt с единственной веткой). Break при истинном условии выполняет свой фрагмент и отбрасывает остаток объемлющего фрейма.
Состояния (скруглённые прямоугольники), переходы-стрелки с событиями, начальное псевдосостояние (закрашенный кружок) и конечное («бычий глаз»). Объект всегда ровно в одном состоянии; переход срабатывает только по своему событию, остальные события игнорируются.
Ромб — исключающий выбор: поток пойдёт по одной ветке в зависимости от условия. Fork (жирная черта) — параллелизм: поток разделяется, все ветки выполняются одновременно, и их собирает синхронизатор join.
Классов и состояний — для разработки структуры решения; деятельности и последовательности — для согласования логики. Чаще всего разработчики сталкиваются с диаграммами последовательности: по ним реализуется детальная логика взаимодействий.
Диаграммой состояний: она описывает состояния одного объекта и условия переходов между ними — включая тонкие случаи вроде «можно ли отменить отгруженный заказ» (есть ли соответствующая стрелка).

Источники

Валитова, Д. Основы UML. Кому и зачем он нужен // Systems Education : [сайт]. — URL: https://systems.education/who-uses-uml (дата обращения: 08.07.2026).
UML-диаграммы: что это, какие бывают и как их использовать // Weeek : [сайт]. — URL: https://weeek.net/ru/blog/uml-diagrams (дата обращения: 08.07.2026).
OMG Unified Modeling Language : Specification 2.5.1 // Object Management Group : [сайт]. — URL: https://www.omg.org/spec/UML/2.5.1/PDF (дата обращения: 08.07.2026).
UML State Machine Diagrams // uml-diagrams.org : [сайт]. — URL: https://www.uml-diagrams.org/state-machine-diagrams.html (дата обращения: 08.07.2026).